I think that it's not really needed to test all [Split]Index{32,64}

I agree that the index would be unexpected here but we should test at least one of Split[U]Int{16,32,64}

I think that it's not really needed to test all [Split]Index{32,64}

I agree that the index would be unexpected here but we should test at least one of Split[U]Int{16,32,64}

All fundamental column types are tested in types.fundamental, so I think we don't need to exercise them here. The selection of Int32, String, and Vector is to have one fundamental type and two "collection" fields. From the optional's point of view, there is no difference between Int32 and SplitInt32.

The reason we might want to consider [Split]Index{32,64} is that it's the primary column type of the RNullableField to encode if there is an element or not. But I think we are exhaustively testing it for vector and soon set and map.

From the optional's point of view, there is no difference between Int32 and SplitInt32.

The question, though, is: do we test that assumption? (the assumption might be accurate (and guarantee to stay that way) for our implementation, it may not be for an alternate implementation).

From the optional's point of view, there is no difference between Int32 and SplitInt32.

The question, though, is: do we test that assumption? (the assumption might be accurate (and guarantee to stay that way) for our implementation, it may not be for an alternate implementation).

No, as discussed in January: We don't want to (and cannot) test all combinations of all fields and all column types. Note also that the goal of the validation suite is not to provide extensive unit tests for all possible implementation issues, it is specifically about the binary format.

Discussion from the IO meeting: in the end we may want to exercise all [Split]Index{32,64}, but only for one element type (std::int32_t). Thought right now: then we can also use those extra fields to use a SplitInt32 encoding for the element field

then we can also use those extra fields to use a SplitInt32 encoding for the element field

On second thought, that's not a great idea because if we do this consequently, we would only have split encodings inside collections of split index encodings. Let's go with the originally agreed approach to assume separation of column encodings.